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TELECOMMUNICATIONS REWARD METHOD 

pmfd Of The Invention 

The present invention relates to telecommunications reward 
methods and is particularly concerned with the rewards based on 
5 consumer purchases. 

R a r*ofound Of The Invention 

The use of loyalty rewards programs to retain existing customers 
and to entice new ones to purchase or use a particular product has 
become persuasive amongst retailers from grocery chains to petroleum 

10 companies and also amongst credit card companies who provide a 

reward of some sort or another for using their card rather than a 
different credit card. One of the problems with these reward programs 
whether it is air miles for gasoline purchases or credits toward an 
automobile purchase for using a particular credit card, is that they do 

1 5 not provide something which has immediate value to the participant in 

the rewards program. 

Summary O f The Invention 

An object of the present invention is to provide an improved 
telecommunications reward method. 

20 In accordance wRh an aspect of the present invention there is 

provided a method of providing telecommunications rewards to a 
member comprising tha steps of generating a point-of-sale transaction, 
relating the point-of-sale transaction to a member of telecommunications 
awards, determining value of reward in dependence upon the point-of- 

25 sale transaction, updating a member's profile for the member by the 
value determined. 

Accordingly the method of the present invention combines known 



PCT/CA96/00198 

WO 96/31848 

-2- 

technologies in such a way as to create a system whereby participants 
in a rewards program can be given telecommunications access time, e.g. 
long distance time, Internet access time or cellular telephone air time, in 
return for purchases and the reward would be credited and available for 
5 use immediately following the purchases. 

The method relates a purchase to an immediate reward for 
telecommunications access time by identifying the purchase as eligible 
for a reward through a member database for example a UPC code 
scanner database or a credit card magnetic strip database which then 
10 communicates to a telecommunications debit platform which in turn is 

interfaced with a long distance or cellular provider. 

Advantages of the pmsent invention are as follows: 

* Providing a link to purchases with instant gratification of 
telecommunications credits, for example in telephony long 

15 distance or cellular minutes and in data communications 

access time to services or the Internet. 

• There is thus no need to save up or receive a statement 
prior to using the credit, a participant in the rewards 
program would be able to utilize the reward immediately 

20 following the purchase for which the reward was granted. 

Rrj «f Description Of Draw ings 

The present invention will be further understood from the 
following description with references to the drawings in which: 

Figure 1 illustrates, in a flow chart, an overview of the reward 
25 method in accordance with an embodiment of the present invention for 
a magnetic strip card user; 

Figure 2 illustrates, in a flow chart, an overview of the reward 
method, in accordance with an embodiment of the present invention an 
overview of the method for a UPC code card holder; 
30 Figure 3 illustrates, in a flow chart, the reward method in 
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accordance with the embodiment of the present invention; 

Figure 4 illustrates in a block diagram apparatus used by the 
method of Figure 3; 

Figure 5 illustrates, in a flow chart, an overview processing data 
5 flow for the reward method of Fig. 3; 

Figure 6 illustrates, in a block diagram, input activities of the 
method of Fig. 3; 

Figure 7 illustrates, in a block diagram, reward transfers; 
Figure 8 illustrates, in a flow chart, the file processing data flow 
10 for the reward method of Fig. 3; 

Figure 9 illustrates, in a flow chart, member lead processing data 
flow for the reward method of Fig. 3; 

Figure 10 illustrates, in a flow chart, member enrollment 
processing data flow for the reward method of Fig, 3; 
5 Figure 11 illustrates, in a flow chart, the reward transaction 

process for the reward method of Fig. 3; 

Figure 12 illustrates, in a flow chart, transaction processing data 
flow for the reward method of Fig. 3; 

Figure 13 illustrates in a block diagram outbound activities for 
apparatus used by the method of Figure 3; and 

Figure 14 illustrates, in a flow chart, statement processing data 
flow for the reward method of Fig. 3. 

Referring to Figure 1 there is illustrated in a flow chart an 
overview of the method in accordance with an embodiment of the 
present invention. 

At step 1 , as represented by a card 1 0, a point-of-sale transaction 
is initiated. 

Step 2, a member card is swiped through a magnetic strip reader, 
as represented by a block 12, as in a typical point-of-sale transaction. 
Step 3, a credit card (or debit) card database is accessed, as 
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represented by a biock 14, to confirm the transaction. Thus far the 
method proceeds as is well known with point-of-sale transactions. 

Step 4, a field in the card holder record, in the database 14, 
identifies the card holder as a member of the reward plan. Responsive 
5 to the presence of this identification a datalink is established, as 

represented by block 1 6, to an appropriate debit platform, steps 5a and 
5b, as represented by blocks 18 and 20. For simplicity, only long 
distance 1 8 and cellular 20 debit platforms are illustrated. However, the 
actual debit platform used could be a telecommunications services 

10 platform. The telecommunications services platform could credit the 

member with long distance or cellular time or a host of other services, 
such as Internet access time, voice messaging, call waiting, and calling 
number identification. Individual member profiles could be used to 
distribute rewards between the various services or to other users. For 

1 5 example to a daughter away at University. 

The rewards method is completed by step 6, by the member using 
the telecommunications reward, as represented by block 2. 

Similarly Figure 2 illustrates an overview of the method for a 
member having a UPC type card at step 1 , as represented by a UPC card 

20 24. 

At step 2, a member's card is held to a UPC code scanner, as 
represented by block 26, as is typical in a point-of-sale UPC transaction. 

At step 3, a UPC code card database is accessed, as represented 
by a block 28 to confirm the transaction. 

25 At step 4, a field in the current holder record in the database 28 

identifies the cardholder as a member of the award plan. Responsive to 
the presence of this identification a data link is established as 
represented by block 16. The remaining steps in the method are the 
same as in Figure 1 . 

30 Referring to Figure 3 there is illustrated in a flow chart a reward 

method in accordance with another embodiment of the present 
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invention. 

The method begins at step 1 with a point-of-sale transaction 
being collected, as represented by block 30. Step 2, transactions are 
aggregated and sorted as represented by btock 32. An associated 
transaction file, as represented by block 34 is created by the first and 
second steps. At step 3, transactions are rated to determine number of 
seconds to be rewarded, as represented by a block 36. In order to 
accomplish this rating, a rewards rating table, as represented by block 
38, is consulted. At step 4, any special treatment required for members 
is determined and rewards are calculated. Special treatment is 
determined by consulting a member profile, as represented by block 42, 
and a rewards file is created as a result of step 4, as represented by 
block 44. At step 5, the member's profile is examined and rewards are 
updated on the member file, as represented by block 46. The updated 
member profile is represented by a block 48. At step 6, a master 
update process is performed on a debit platform as represented by block 
50. A debit system member profile is updated as represented by block 
52. The method is completed at step 7, when a member phones into 
the system and consumes rewarded time as represented by a block 54. 

Referring to Fig. 4, there is illustrated a reward system 100 
comprising a high-level control centre (HCC) 102 and an information 
works (IW) 104. The IW 104 includes a transaction processor (IW/TP) 
1 06 for partner management, member management, and reward system 
calculations and an data warehouse (IW/DW) 108. The HCC 102 
includes a Customer Service Centre (CSC) system 110 and a debit 
platform with interactive voice response (IVR) 112. 
The method is a database-driven relationship marketing program, 
there are four distinct business components. 

Transaction Processing (IW/TP) Database Management System 106; 
Data Warehouse (IW/DW) Database Management System 108; High- 
level Control Centre for Debit Platform 102; and IVR systems (IVR) 
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112. 

Now to address the system functionality as well as describe the inter- 
relationship of the Customer Service Centre, Debit Platform and IVR 
components with InfoWorks' components: Transaction Processing 
and Data Warehouse Database Management Systems. 

Referring to Figure 5, there is illustrated, in a flow chart, an overview 
processing data flow for the reward method of Fig. 3. Advantages of 
the present system are: 

* Immediate gratification with "real-time" reward accumulation and 
redemption. 

* Conceptually unique, technology-based coalition loyalty program. 

* High appeal, easily attainable reward currency. 

* Preemptive opportunity to link land-based long distance with cellular 
mobility. 

* Debit Platform offers enhanced customer telecommunications services. 

* Opportunity for value-added credit card overlay with innovative functional 
enhancements. 

* CommitiBent to data driven Customer Value Enhancement strategies for 
partners. 

* Network time. Debit Platform, and marketing databases supported by blue 
chip providers. 

* Longer term opportunity exists for Members and Partners to ride the 
information highway into direct-to-home entettamrnent/informatica) ser 

* Global expansion opportunities with significant ROI. 
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Overview of Reward Process 

* Members in the program earn their points 

automatically through electronic Point of Sale (POS) tracking when they shop 
at participating Partner. 

The IW/TP System collects and processes the Member purchase transactions 
and assigns the appropriate reward points. 



The reward redemption process includes calling the IVR system via a 1-800 
telephone number, 24 hours a day, 7 days a week: Members will call a 1-800 
number, Enter their unique Member Number and password. Place a calf with 
a telephone number of their choice 



The HCC/Debit Platform is the data manager of the redemption process and is 
the vehicle that Members use to redeem their reward points. 

HCC/TVR platform is a voice-assisted telephony system. The IVR system is a 
vehicle for: Customer Service, Program Information, Member Enrollment, 
Customized advertising, Branded messaging. Branded marketing surveys. 

For service. Members may access a live operator at the CSC (Customer 
Service Centre). 



Database Management Systems 

Data Warehouse and Transaction Processing Database Management Systems 
allow for an extremely flexible environment supporting several basic, but 
different business functions. Together, they support: 
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• Integration with a first class customer service system 

• High volume transaction processing 

• Detailed management reporting and EIS systems 

• Partner reporting 

• Basic analytics and the IW Customer Value 
Scorecard™ 

• Marketing information retrieval and advanced 
analytics 



Objectives of the Database Management Systems 

• Design and support a system that is driven by the anticipated 
marketing information requirements, with the flexibility to adapt 
to changing market dynamics. 

• Ensure seamless connectivity between the Database Systems, 
Customer Service Centre, Debit Platform, IVR and external 
suppliers and vendors. 

• Ensure data integrity by developing appropriate edits, controls, 
audits and procedures. 

• Meet the growth requirements of the program in terms of 
membership, partnership, and more detailed transactional data, 
i.e. product categories or SKU. 

• Ensure the system architecture has the necessary through-put 
and offers flexibility, scalability and portability to manipulate 
and report information in the database . 

• Continuously enrich the Member Profile information though 
survey data, file overlays and tracking of response data. 
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• Deliver dynamic analytic services to support Customer Value 
Enhancement (CVE) marketing strategies. 

The development of the functional design, system specifications, 
programming, simulation, training and implementation of the 
system will take place as two deliverables. 
IW/TP System Architecture-Pipeline and parallel processing 
The architecture of the IW/TP engine will include many asynchronous 
processes to handle different stages of transaction processing. The processes 
will be similar for each transaction type; they will be kept simple; and they 
will support pipeline and parallel processing. This architecture allows many 
processes to be reused for different transaction types. Communication 
processes can be common to many transaction types and for many parties. 
Separate processes to handle the communication links, to load transaction files 
into the database; and to process the transactions within the database will 
simplify the maintenance of the programs. Simple changes to file formats and 
support for new communication methods could be implemented without 
touching the transaction processing processes. The migration from a batch 
engine to a real-time engine could be done quickly by providing a new loader 
process on top of the existing processing processes. 

Inbound Processes 

The processes (or software modules) for an Inbound transaction will be: 

* File reception (from communication line or media), 

* Basic file validation (number of trans.; transaction formats), 

* File segmentation (broken into "work" units), 

* Segment loading (in a work area), 

* Segment validation and computations (still in a work area). 

- Detect and log validation errors 

- Compute any necessary quantity (Rewards, Offers) 

* Segment insertion (into final database) 

Referring to Figure 5, there is illustrated, in a flow chart, processing data 
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flow for the system. And in Figure 6, there is illustrated, in a block diagram, 
input activities of the system. 



Outbound processes 

The processes (or software modules) for an outbound transaction will be: 
5 * Create outbound transactions (select a set for transmission). 

* Create outbound fife (for outbound transactions) 

* File transmission (to communication line or media) 

Transaction Types and Input Activities 

* Member Lead {prospect data) 

10 * Member Enrollment (basic Member data) 

* Member Profile changes (demographics) 

* Member Purchases (POS transactions sent by Partners to 
IW7TP) 

* Reward Credits (Member Base Offer and Special Offer 
15 points) 

* Reward Debits (Debit Platform redemption of points ad 
call detail data) 

* Reward transfers 

* Member IVR Message control (what messages to play) 
20 * Member IVR Response {responses to branded messages 

and surveys) 

* Customer Service Messages (problems and resolutions 
about Members) 

* Fulfillment Request message (control for Member 
25 fulfillment) 
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* Mail-Out Message Flags (Fulfillment) 

* Database Synchronization {shared table 
additions/updates) 

* Transaction Acknowledgment (processing audit 
control!. 

Member Lead (ML) 

A prospect may enroll into the reward system program 
using one of the various methods that are available: 

• Customer Service Centre 

• ivr 

• Mail-in order form via Data Entry 

• Internet* 

• Electronic Kiosk * 

• Parmer "auto-enrollment" information 

• Partner "auto-prospect" information 

Regardless of which enrollment method is chosen, a new Member Lead 
transaction is generated and sent to IW/TP. 

The transaction layout is the same as the Member Enrollment (ME), except 
the transaction identifier is "ML" and the Member Number must be blank. A 
unique reference number is assigned to the transactions and stored in the 
MEMBERLEAD table. CSC is responsible for returning a clean Member 
Enrollment (ME) transaction with the assigned reference number. This 
reference number will be used to update the MEMBER LEAD table as 
accepted or rejected. If the lead is rejected, a reason code will be provided by 
CSC. 
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Referring to Figure 10 there is illustrated, in a flow chart, member enrollm* 
processing data flow for the reward method of Fig. 3. 

Rewards Module 

Partners Rewards- Partners are responsible for capturing the reward system 
data and sending it to FTC. Members (using the reward system card) will 
earn points for each dollar spent at a Partner's location. Members will have 
options on "what" currency types they wish to use when redeeming their 
points, i.e. Long Distance minutes. Cellular minutes, etc. 

Data Capture 

There are several methods in which a reward system transaction can be 
captured and sent to the Parmer Host. The methods are as follows: 

* POS Direct - data is captured via card swipe at the Partner POS. 

* F.I Terminal - data is captured on a Financial Institution Tenninal 
(Credit/Debit). 

* reward system Terminal - data is captured on a standalone reward system 
terminal. 

* Record of Charge - data is captured on chits/paper. 

* PC Direct - data is entered and captured on a PC. 

Reward Credit Transaction Process 

Once the transaction is received at the Partner Host, the following process is 
executed: 

The Partner then generates a Member Purchase (MP) transaction and sends it 
to the rW/TP. Procedures and Standards for Data Capture will be provided 
by FTC to the Partner. 

IW7TP receives and validates the MP transaction by Member Number, Parmer 
ID, Partner's store location ID, offer codes. Any errors are flagged and 
reported to the Partner. 
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Reward points arc likely to be pre-calculated by the Partner. However, 
IW/TP must verify the points in any case. Using the Offer rate table, the 
reward points are calculated. 

The reward points are analyzed for fraud by comparing the points to pre- 
defined Partner thresholds. Any suspected transactions are flagged as 
"suspense" and FTC is notified for manual verification. 
IW/TP generates a Member Reward Credit (RC) transactions. IW/TP will 
also manage Member and Partner point accumulator buckets. 
The RC transactions arc transmitted to HCC. The RC transactions are storel 
HCC receives the RC transactions and updates the available points for the 
Member on the Debit Platform 

The CSC will receive the Reward Credit Transactions via HCC from IW. 
Reward Transaction Triggers 

All of these triggers represent a Reward Credit transaction type. Each has * 

own set of business rules: 

Members purchase at a Partner's store 

Purchase of a specific item (bonus offer)Purchase of a specific offer of doutk 
or triple the BASE 

Accumulation of points over a pre-defined time period 

Transfer from one Member Number to another Member Number (account) 

Discretionary award from Customer Service Representative 

IVR rewards for completing surveys 

Promotional reward of units 

Reward Redemption 

HCC is responsible for managing the Debit Process. This debit process, 
commonly known as redemption is initiated when a Member consumes or uses 
a part of their reward points. IW manages the Member purchases to reward 
"points" conversion process. HCC manages the reward point to "currency" 
conversion process based on the method of redemption, i.e. Long distance, 
cellular, video, Internet. 
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Reward Debit Transaction Process 

When the Member redeems his/her points, HCC debits their point balance 
based on the type of currency used to redeem the points, i.e. 1 cellular minute 
= 2000 points. A Reward Debit transaction is generated and transmitted to 
IW/TP to keep the systems synchronized. 

Reward Credit Processing 

Rules and standards apply for Credit processing. The rales and standards 
must be authorized by reward system and will vary depending upon the 
Partner. IW and the CSC can generate credits for a Member (upon 
investigation). If IW initiates the credit, a Member Reward Credit 
transaction is created and transmitted to HCC. If the CSC initiates the credit, 
a Member Reward Credit transaction is created and transmitted to IW. Tie 
Member's account will be credited instantly, allowing immediate redemption. 
Referring to Figure 11 there is illustrated, in a flow chart, the reward 
transaction process for the reward method of Fig. 3. Referring to Figure 12 
illustrates, in a flow chart, transaction processing data flow for the reward 
method of Fig. 3. 

DATA WAREHOUSE 

Analytical Processing will render the mass of Transaction, IVR and Customer 
Service data intelligible and actionable to these reward system stakeholders: 



• Parmer Marketing Team 

• reward system Account Managers 

• reward system Program Management 

• InfoWorks System A dmini strator 

On-Line Analytical Processing (OLAP) is a system for storing, analyzing, 
reporting and viewing information about the activity of reward system 



96/31848 



FCT7CA96/00198 



- 26- 

Members. OLAP is distinguished from the TP (Transaction Processor) in 
these ways: 

Storage- Transactions are stored for years, not for only 3 months; 
Database- Tables are optimized for fast, flexible data access; 
Processing- Specialized functions for marketing analytics 



The OLAP System has these major components: IW Data Warehouse (DW) 
for storage and de-normalized tables for accumulating Member transaction 
data (detail level data), archiving system for low-cost storage and rapid 
retrieval of old detail data. 

IW Analytical Processing (AP) for marketing-statistical software procedures 
for reporting and segmenting. 

Partner Report Repository for file storage and access method for historical 
reports. 

Partner Marketing Databases (MDB) subsets of data warehouse designed for 
marketer access at Partner level. 

Graphical User Interface (GUI) to provide 'slice & dice' views of the MDB 
for the FT Account Manager and to provide OLAP system control for the 
InfoWorks System Adrninistrator. 
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Processing How includes the steps of: 

Validate Input, Running Totals, Upload Format, TP Unit. Procedures. 

Data Warehouse 
Data Collection from IW/TP 
5 The TP will act as a central point of data collection for these reward system 

data sources: 

Member transactions from the Partners : Partner transmissions 
Reward accounting by the TP : IW TP Center 

Debit Platform and IVR activity : HCSC activity 

10 High-level Control Center 

Data Entry 

Transferring Data from Data Warehouse to IW/TP 
After download to the Data Warehouse, some analytical procedures will 
generate Member data values which may be of use in these TP functional 
15 areas: 

Member Reward Status input variable in logic for bonus rate 
calculation based on Member segment status i.e. Gold, Silver. Bronze 
Members IVR custom messaging flow through to IVR 
Mail-out messaging flow thru to statement fulfillment house 
20 The Analytical Member data will be processed as a special transaction sent to 

the TP on a WEEKLY basis, taking place after that week's download has 
been analyzed. 

The InfoWorks- Data Warehouse (IW/DW) stores reward system data to 
support the reporting, viewing and analytics functions. The DW has three sub- 
25 components: 

• Physical Storage Units (ex: DASD drives) 

• Database System (ex: Sybase) 
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• Database Server (ex: Sun 1000)* 

• Archive System (tape or optical jukebox) 
Referring to Figure 13 there is illustrated in a block diagram outbouii 

activities for apparatus used by the method of Figure 3 

Referring to Figure 14 there is illustrated, in a flow chart, statement 
processing data flow for the reward method of Fig. 3. 



Debit Card Platform 



10 



15 



The reward system PCS system comprises a front end voice applicatiot 
that has its own unique call flow as well as a back end database component 
that will suit the data requirements of the reward system. 

The Control Centre 102 is the interface to the debit platform 112. It 
has access to tables in the reward system PCS database and is able to perform 
reward system and batch updates. The reward system PCS system requires 
access to the HCC 102 tables in order to provide some of the features 
required by the reward system. 

The main functions and features required for the reward system PCS 
debit platform 1 12 are described in the following pages. 

The reward system PCS has its own separate master database. 

The tables that are the main concern are the CARD NUMBER, 
20 CONSUMER JTAIXLOG. and CONS_OUTBOUND_LOG tables. 

It is also more efficient to keep the reward system call detail records 
separate because large call volumes are expected and reward system will be 
using the call detail records for queries by the Customer Service Centre and 
for its own analytics. Call detail records are currently stored in the PCS node 
25 databases but will need to be written to the central master database so that 
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they are accessible to the reward system from one centralized location. 

The reward system member will choose their preferred IVR language 
during enrollment. This choice will be validated against the choices available 
on the IVR and will be stored in a language field on the reward system PCS 
CARD NIFMBER table and in an IVR language field on their member 
profile. A member's household language is also recorded on their member 
profile so that analytics can be performed to determine the best options for 
future languages in the IVR. 

At launch, English and French are the two languages that need to be 
available on the debit platform. More language options will be required as the 
campaign progresses and will be incorporated by simply recording all voice 
prompts in the new language and making a minor system change to the reward 
system front end voice application to recognize and act on the new language 
code. 

When a member calls into the PCS system, they will be played a 
"welcome- message and a "request for member number" message in all IVR 
languages. Experienced members will know to immediately key in their 
member number rather than listen to the entire voice prompts. Once the 
member has entered their member number the call will proceed in their 
chosen IVR language. All voice within the call flow will be played in the 
member's language including branded messages and surveys. 

In an alternative of the reward system PCS, a function will be available 
within the IVR to allow the caller to change their language choice (this will be 
particularly useful as new languages are added to the IVR). This "change 
language- function will be a sub-option under the administrative options on 
the main menu. If a member chooses to change their language in the IVR their 
current call must continue in the new language and the change must be 
immediately reflected on the reward system PCS CARDNUMBER table. 
Also, a member transaction to the CC must be created to update their member 
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profile. Until this function is implemented, the member can change their IVR 
language through the Customer Service Centre. 

Each reward system member number (card number in PCS) will haw a 
password associated with it. This password will be chosen by the member 
when they first use the debit platform. It is personal to the member and wifl 
not be visible to anyone. 

A flag may be added to the CAMPAIGN table to indicate whether a 
campaign uses passwords. As well, a field has been added to the 
CARDNUMBER table to store the password for the card. The password 
length is currently set at 4 characters. A change will be made to increase the 
length of the password field to 10 characters and allow the IVR to accept a 
variable length password (minimum 4 to maximum 10 characters). A 
password reset flag will also be added to the CARDNUMBER table so that 
the member can be prompted to choose a new password on their next call. 

When the member is initially setup in the PCS system their password 
will be Wank and the password reset flag will be set to Y to indicate that a 
password needs to be chosen. When the member first calls into the IVR thej 
will be prompted to initialize their password. The member must enter a 
password which is then validated (4 to 10 characters). The member is then 
asked to re-enter their password for verification. If the two passwords are 
identical, the member's password is set otherwise they must begin the entire 
routine again. On subsequent calls, the member will be asked, to enter their 
password immediately after entering their member number (the member 
number is validated first). 

A function will be available within the IVR system to allow the caller 
to change their password. This will be a sub-option under the administrative 
options on the main menu. If a member forgets their password, a procedure 
will be in place that will allow a Customer Service Centre agent to reset it 
(this will be an audited process). 
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During the call flow, the member wfll be presented with a main mem 
of IVR options. The entire menu will be soft prompted such that the caller ca 
make their selection at anytime while the menu is played. 

The primary categories on this main menu will be: 

** To listen to messages, participate in surveys, and earn reward 
system units, press 1 

** To place a call, press 2 

■* For administrative options, press 3 

=» For program and/or partner information, press 4 

~ To speak with a reward system customer service centre agent, ores 



Additional menu options can be added as required with the 
recommendation that the zero out to the CSC option always be played last. 

A sub-menu will exist under the messages/surveys option and will be 
presented to the caller when they press 1 . The primary categories on this 
menu will be: 

-* To listen to messages from reward system Partners, press 1 
"* To participate in surveys or games, press 2 
■* To return to the main menu, press * 

"* To s P cak with a reward system customer service centre agent, press 

0 



The place a call option will lead the caller through entering the 
telephone number for their outbound call. 
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A sub-menu will exist under the administrative option and will be 
presented to the caller when they press 3. The primary categories on this 
menu will be: 

** To change your password, press 1 

«=» To query your account balance, press 2 

=> To transfer units to another member, press 3 

«* To change your language choice, press 4 

«=» To return to the main menu, press * 

=» To speak with a reward system customer service centre agent, press 



A sub-menu may also exist for the program and/or partner information 
option but will be designed as needed. This may include topics such as "to 
hear a list of reward system Partners", "to leam more about the reward 
system program", etc. 

The caller will be guided within the call flow to enter the digits for 
their outbound call if they have enough units in their account for a one minute 
call at the lowest rating level (eg. local call). The caller will be able to place a 
national or international call provided that they have at least enough units 
remaining in their account (after rating) for a one minute call. 

Outbound calls to regions within the North American Dialing Plan will 
be rated based on their npa and nxx in conjunction with the npa and nxx of 
the caller. International calls will be rated on the country code that was 
entered. 



25 



With only 1 minute remaining in the call, the caller will be prompted 
with a warning message which states that there is only 1 minute remaining for 



WOSW3I848 



PCT/CA96/00198 



- 33 - 

the call. A second warning, with only 10 seconds left, will also play. After 
their time has been used, the caller will hear a "Your time is up" message and 
will be disconnected from their outbound call. The calier may also disconnect 
from their outbound call by pressing the # key. The caller's account will be 
immediately updated to reflect the time used. The duration of the call will be 
rounded up to the next minute and this time amount will be translated to units 
based on the rating scheme for the call. After placing a call (either 
successfully or unsuccessfully), the caller will hear their new balance and will 
be presented with the main menu. 

An outbound call that consumes a member's units will also create a 
consumption transaction to the CC platform for audit purposes and to update 
the member's balance on their member profile. 

The member will be able to obtain their current account balance within 
the IVR. A member's account balance is played to them before the main menu 
is presented. 

If a member earns additional reward system units by participating in a 
survey. listening to a special branded message, or playing an interactive game 
then their updated balance may be spoken to them to assure them that they 
have received their reward. 

After a member has entered the digits for their outbound call, the IVR 
will speak their account balance in terms of how many minutes they have 
avaDable for the call they have just placed. This balance of time will be 
calculated based on the rate of unit consumption for that call and will be 
rounded down to the nearest minute. For example, if they have 6 units 
remaining in their account but are placing a call that has a 3 units : 1 minute 
rating ratio, then this rated balance will read "You have up to 2 minutes for 
ibis call". If a member's rated balance does not allow for at least a one 
minute call, they will not be played their balance but will instead be told that 
they do not have sufficient units to place the call. 
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After a member has ended an outbound call, they will be played their 
new account balance and returned to the main menu. 

Branded messages will be offered at two points within the IVR call 
flow. Type A messages are typically short messages (5 - 10s) and are slotted 
5 to play after the member has entered their member number and password. 

Type B messages are typically longer messages (5 - 30s) and will be available 
under option 1 on the main menu ("To listen to messages, participate in 
surveys, and earn reward system units, press 1"). Type A messages can be 
recycled and played with Type B messages so that a member has the 
1 0 opportunity to listen to them again. After the member has entered their 

member number and password, the IVR system will check the CC 
MEMBERMESSAGE table to determine whether the member has any Type 
A branded messages that should be played at this time (complete or expired 
messages are not considered). The next message to be played for a member is 
1 5 based on which one has the highest priority and is the oldest within that 

priority level. A message code is returned from the MEMBER MESSAGE 
table which must then be translated to a voice segment. The message code is 
looked up in the CC BRANDEDMESSAGE table to determine which voice 
segment to play, the type of play (hard or soft), and whether there is a reward 
20 for fully listening to the message. The message is then played to the caller. 

If the caller presses a DTMF key before the end of a soft play message 
(but after 2s of play) then a message transaction record is created with the 
message code, the member number, the length of time the member listened to 
the message, and a "partially listened" status. If the caller fully listens to the 

25 message then a message transaction record is created with a "fully listened" 

status. If the message was fully listened to and a reward is offered, the 
member's account must be immediately updated to reflect the reward and a 
reward transaction must be created and sent to the CC for audit purposes. If 
the caller pressed zero before the branded message finished playing they will 

30 be transferred to the CSC (any other key will not have an action associated 
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with it). The member's account balance is played after the branded messa* 
It must reflect any additional reward that was given for listening to the 
branded message. The member will hear a maximum of 1 branded message 
per call. If the branded message is flagged as recyclable, then the message* 
Priority for that member is lowered so that it will be considered again but * 
after other messages have been considered. If it not recyclable, then the 
message for that member will be flagged as complete. 

If the caller chooses option 1 on the main menu and then selects to 
listen to branded messages, they will be presented with all Type A and Type 
B branded messages. The branded messages will be ordered based on prior* 
and age. If the message is soft play, the member will have the option to 
interrupt by pressing a DTMF key which will stop the message from playu* 
The caller will be instruct that the # key is to be used to interrupt/skip a 
message. With this interrupt, or when the message had finished playing, the 
caller will be presented with three options. They can listen to the message 
again, move on to the next message, or return to the menu. After a message 
has been listened to (either fully or partially) a message transaction records 
be created. If there is a reward for -fully listened to" messages, then the 
member's account is updated with the reward and a reward transaction is 
initiated. If the message is flagged as recyclable then the priority of the 
message is lowered so that it moves further down in the queue otherwise. 
message is flagged as complete and will not be offered to the member again. 

Surveys and interactive games will be offered through optiw 
1 on the main menu ("To listen to messages, participate in 
surveys, and earn extra reward system units, press 1"). 

If the caller selects option 1 from the main menu and then 
selects to participate in surveys and games, the IVR system will 
check the CC MEMBER_SURVEY table to determine whether the 
member has any surveys or interactive games to present at this 
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20 



25 



time. The member will be able to participate in all surveys or 
games that have been assigned to their member number. The ordfcr 
in which these surveys are to be presented for a member is base* 
on which survey has the highest priority and is the oldest within 
that priority level. The survey codes are returned from the 
MEMBER_SURVEY table and must then be translated to a state 
table name for each survey. The survey code is looked up in the 
CC SURVEY table to determine which state table to invoke and 
whether there is a reward for completing the survey. By branding 
to a state table, this survey and game feature is very flexible and 
can involve anything that is possible within the IVR world. 

The beginning steps of a survey or game will include a braf 
explanation of what it is about. For example, "Partner X will 
reward you with 5 reward system units to answer the following 
1 5 survey". The introduction will also give the caller an option to 
continue or skip. If the caller chooses to skip the survey or game 
they simply move on to the next survey that was assigned to them. 
If the caller continues and partially completes the survey or game 
then a decision is made within the survey or game whether it 
should be made available to the caller again (either to complete or 
to redo). A decision will also be made within the survey about 
creating a survey transaction record for partially completed 
surveys. If the caller fully completes the survey then a survey 
transaction record is created and the survey for that member is 
either marked as completed or it is recycled by lowering the 
priority. If the survey was fully completed and a reward is offered, 
the member's account must be immediately updated to reflect the 
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reward and a reward transaction must be created and sent to CC 
for audit purposes. The actual results of a survey or game will be 
transmitted (if necessary) via the CC to the transaction processing 
kernel for analytics. This transmission of results will not be a 

standard transaction as the data produced by a survey or game wiH 
vary depending on the survey or game. 

Wherever a menu selection is offered in the IVR system, an 
option on this menu will be to zero out to the customer service 
centre (To speak with a reward system customer service centre 
agent, press 0"). Most of the voice prompts that are played to the 
caller are soft play and can therefore be interrupted at any time by 
a DTMF key. If a menu follows one of these prompts then a caller 
pressing zero during the prompt will transfer their call to the CSC. 
For example, the member is listening to their account balance and 
presses zero. This zero interrupts the playing of the account 
balance and is interpreted the same as the caller waiting for the 
main menu to play and then pressing zero. The member can also 
zero out to the CSC while listening to a soft play branded message. 

There will also be a tunable option (turn it on or off) that 
will automatically zero out a caller to the customer service centre 
when they appear to be having difficulty using the IVR system 
For example, the caller was given two tries to enter their member 
number but the IVR did not detect a response. The caller will be 
toW they are being transferred a CSC agent and can choose to 
either stay on the line or hang up. The CSC agent can then assist 
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the caller in determining their difficulty (rotary phone, insufficien 
time, etc). The caller could also be transferred to the CSC if they 
appeared to be deliberately trying to defraud the system (eg. 
member number hunting or guessing passwords). 

5 Alternatively, a transfer to the customer service centre cou« 

be accompanied by a screen pop based on member number 
information and perhaps based on where the caller was in the FVK 
when they pressed zero. The CSC agent will then be able to better 
assist the caller as they would already have an idea why the caller 
1 0 was transferred to the CSC. 

Once in the IVR system (member number and password haw 
been entered), the caller should be able to transfer units from their 
account to any other valid member's account in the reward system 
PCS. This option will be available on the administrative options 
15 sub-menu. 

When the caller chooses the member to member transfer 
option, they will be asked to enter the number of units they wish m 
transfer. Once the system has validated that the caller did not entei 
an amount greater than their account balance, the caller will be 

20 asked to enter the member number to which they wish to transfer 
the units. The system will then verify that the "transfer to" 
member number is valid. The caller will not be asked for the other 
member's password. The "transfer to" member number and the 
number of units to transfer will be repeated to the caller. The 

25 caller will be given the option to continue (if the information is 

correct) or restart (if the information is not correct). A member to 
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member transfer will immediately update the two members accoum 
balances. A consumption transaction will be created for the 
"transfer from- member and sent to the CC for audit purposes and 
to decrement the member's balance in their member profile. A 
5 reward transaction will be created for the "transfer to" member 
and sent to the CC for audit purposes and to increment the 
member's balance in their member profile. Note: the alternative 
option being considered is to send a special member to member 
transfer transaction to the CC for audit purposes. 

> Another alternative is to support cellular debit calling. Asa 

result of the mobile nature of the caller, issues such as location of 
the caller (roaming or out of home area) must be considered. The 
caller dials something like *99 to connect them to the reward 
system debit application through which they will enter their 
member number and password and place their call. The rating (unit 
consumption) for a cellular call may be different than for a land 
based call and may also involve a long distance debit. The member 
will only have one account of units from which either land based 
or cellular calls are debited. 

The IVR system may be able to expand to include other 
options without significantly changing the current options - so as to 
avoid confusion for the caller that has become experienced at using 
the system. Other functions may include: faxing of account 
information (may consume units); information services (eg. sports, 
horoscopes) that may consume units per use; etc. 
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2.0 Customer Service Centre 



The Control Centre will be the interface to the reward system 
Customer Service Centre. Ail information that is required for the CSC screw 
will be derived from the CC databases and the debit platform databases. 



10 



15 



The Customer Service Centre will have a screen based application to gather 
and access reward system data. The CSC agent's screen is populated with 
member profile data as the call is being transferred (provided that the caller 
zeroed out from the application after entering their member number). 

The following pages contain details on the main areas of functionality 
for the CSC application. 



* Explain the loyalty program 

Explain to members and non-members the reward system concept, who 
the partners are, how to enroll, how to gather and use uMts. the rating 
schemes of the different partners, etc. This herniation may either be stored 
online or in a manual at each agent's workstation. 



• Create fulfillment requests for members 

Generate a fulfillment request in the reward system to initiate a mailouc 
of information. 
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• Explain branded messages and surveys 

Give assistance about listening to branded messages, answering 
surveys, or playing tractive ^ ^ m ^ fa ^ ^ 



10 



• Enroll new members into the program 

Agents will be aWe to collect tf pertinent enrollment infonnation fto. 
*• caller into their reward system CSC appiication. ifc app , icatioi) ^ ^ 
t0 f - will allow a completed apphcation to 

be subrmtted to the CC for processing. The enroHee wiil receive their reward 

w«H not know the.r member number until they receive their card) 



• Correct enrollments 



A feature on the CSC application will be to bring forward any 

™= CSC agent wul pllce ^ ffl[ ^ ^ ^ ^ ^ 

Phone number). 



' Quay member profile 
20 Query wW, member mnnber to retrieve member profile information 
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CSC agent and the member as well as to inform the agent of special 
considerations (eg. hearing impaired, gold rated reward system member). 

• Update member profile 

A query will be initiated to retrieve the member profile information ss 
the CSC agent can verify that the caller is the member. The CSC agent can 
then change any of the displayed information (eg. name, address, language). 
Note that a change to a member's spoken language will be reflected on the 
debit platform. 



• Retire or reactivate members 

10 ^^^^todosobyamember.theagentwillbeableto 
initiate a transaction to the CC to retire or reactivate a member. 



• Maintain a contact log 

All calls between CSC agents and members will generate a contact log 
record so that member's comments/complaints/suggcstions can be collected 
and recorded as part of their profile information. 



• Gather member details/statistics 

The CSC agents may be able to gather remarks about a member that 
would be useful in future dealings with that member (eg. hearing impaired, 
preferred calling time frame for accepting calls, etc.). Also, the CSC agent 
may ask the member to answer survey questions either on the inbound call or 
by making outbound calk. 
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• Initiate a password reset 

Once the CSC agent has verified that the caller is the member, the 
agent can initiate a password reset transaction to the CC. This transaction sets 
the member's password reset flag on the debit platform which wUl then force 
them to enter and verify a new password the next time they call into the IVR. 
The ability to do this may be restricted to CSC supervisors as the member will 
be required to give their personal validation number (eg. mother's maiden 
name). 



10 • Handle a lost card problem 

A procedure needs to be developed to handle this - the details of the 
procedure will drive the system requirements. 

The options are a) to try to determine the member's number so that a 
replacement card can be mailed to them or b) to re-enroll the member as if 
15 they had just joined. With option A, a fulfillment request will be initiated to 

the CC to send the replacement card. With option B, a new enrollment 
transaction will be sent to the CC, the member will lose their units and reward 
system will lose any previous data that had been collected on .the member. 

• Create a fulfillment request for additional cards with the same 
20 member number. 



• Unlock a member's card 

A member's card is locked by the PCS system while it is in use. It 
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may remain locked if there was a significant system problem while the 
member was using their card. This unlock process will first verity that the 
card is not locked because it is currently in use, then it will send a request to 
the CC to unlock the card. The unlock will be immediately effective. 

5 • Add units to a member's card 

At the CSC agent's discretion, units may be added to a member's card 
to compensate for a problem. These units can be charged to different sources 
(such as a specific partner). This function will initiate a transaction to the CC 
to immediately update the member's balance and create a 
10 MEMBER REWARD TXN as an audit. 

Member Account Information 

• Query account information 

Query with member number to retrieve the member's card balance and 
a history of debits and credits to their account. 

•5 A member's unit accumulation history consists of reward transactions 

that show how the member acquired their units and from which source 
(purchases at partners, CSC agents, branded messages, surveys, other 
members). If the reward is a summary reward (eg. it is composed of several 
purchase transactions from a partner) then it will be highlighted and the CSC 

!0 agent may perform a drill down operation to further define how that summary 

reward was calculated. 



A member's unit consumption history consists of consumption 
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transactions that show how the member used their units (outbound calls, 
transfers to another member). Outbound calls will show the number that was 
called, the duration of the call, and the number of units that was consumed by 
the call. Transfers will show the member number of the person that the units 
were transferred to. 



Note: This information should be at the same level of detail as the information 
displayed on member statements (3 months). 



CC Transaction Processing 



The CC Transaction Processing centre interfaces to the reward system PCS 
system (debit platform), the reward system Customer Service Centre, the 
Transaction Processing centre, and the IVR Enrollment process. Transactions 
are received from and sent to these interfaces either in a batch or reward 
system mode. The CC TP centre houses transaction databases that are used for 
audit purposes and well as for queries from the CSC and the reward system 
PCS. 

There will be a suite of applications that will handle member 
enrollment. The system design to handle these will depend on the method of 
enrollment. For example, an electronic kiosk may require a direct link to the 
member profile database and may simulate real-time enrollment. An IVR 
application can capture DTMF and voice input to create an enrollment record. 
If enrollments are collected from the customer service centre then screens will 
need to be designed so that the customer service centre agents may enter the 
member information directly into the system. If enrollments are gained 
through amalgamating with already existing loyalty programs then a download 
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file from the new partner's loyalty program may be the best solution 
(however, file format and data transfer issues will need to be resolved). 
Member transactions with a type -enrollment" will be sent from various 
sources in either batch or reward system to the High-level Control Centre for 
validation and processing. 



* Collect enrollment data 

Regardless of the method used to collect the enrollment data from the 
prospective members, the result will be a transaction to the CC (either batch 
or reward system). The format of this transaction (MEMBERTXN) is 
outlined in the reward system Database Design document. 



• Validate enrollment records 

As enrollment transactions arc received, they are validated and 
recorded in the MEMBERTXN table as either new (passed validation) or 
corrections pending (did not pass validation). CSC agents will be able to 
modify transactions that are flagged as corrections pending and resubmit them 
for processing. Any enrollments that originate from the CSC, new or 
corrected, will have been validated online so that they do not recycle 
continuously through the system causing frustration to both the CSC agent and 
theenrollee. 



20 • Assign member numbers 

A process will periodically search the MEMBER_TXN table for 
validated enrollments. A member number will be chosen from the pool of 
unique member numbers and will be assigned to the enrollment to complete a 
new member profile. The member number will be flagged as in use in the 
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MEMBER_NUMBERS table and the new member profile record will be 
added to the MEMBERPROFILE table. 



• Activate the new member 

After the MEMBERPROFILE record has been created for the new 
member, the member wffl be activated on the debit platform by adding their 
member number to the reward system PCS CARD_N UMBER table. 



• Forward member profile to the online analytical processing system 
A batch process will be run at least daily to send the new member 
profiles, with member number, to the transaction processing kernel. The 
transaction processing kernel will add them to their member profile table and 
issue a welcome kit to the new member. The welcome kit will contain the 
member's reward system card with their member number printed on the caixJ. 



* Generate new member numbers 

?5 te^^rtiv^toe^term^tste^nw member 

numbers will be generated and added to the pool (MEMBER_NUMBERS 
table). The generation process will take into consideration all currently 
existing member numbers and will not create duplicates. 



20 



• Manage the member numbers 

When member numbers are assigned to new enrollments they 
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flagged as in use. They rernain m this state unuJ the member retires (or is 
suspended). When a member retires, the member number is removed from* 
deb.t platform (member deactivated) and it is also flagged as retired in the 
MEMBER.NUMBERS table. If the member does not reactivate within a 
speeded period of time then the member number is made available for ma 
Reward system will have to determine a policy with regard to whether a 
member loses their accumulated units by retiring. 



• Database synchronization 

A process will be run periodically to verify that the debit platform 
CARD_NUMBER table remains in sync with the CC MEMBER PROFILE 
table. All member numbers on the debit platform must relate to non-retired 
and non-suspended member numbers in the member profile table and must 
have the same account balance. 

T5 The CC MEMBER_PROFILE table must contain member numbers flB 

match member numbers in the MEMBER_NUMBERS table. The status of * 
member numbers must also be similar, that is an in use number in one table 
cannot relate to a retired number in the other. Numbers that are not in use * 
reared in the MEMBER _N UMBERS table must not exist in the 
MEMBER PROFILE table. 

!0 The CC member profile table must also be verified with the online 

analytical processing system member number table to ensure mat these two * 
identical. 



Memhw Ta ttle Infn^ fi^ 
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Note: The full member profile database to be used for analytics will be 
designed, developed and managed by transaction processing kernel but a 
subset of this database will need to reside in the CC so that member profile ' 
information is available to the customer service centre agents. The information 
collected in the CC will pertain to information that is required during the 
enrollment process; information that can be changed by the member calling 
the CSC; and mfonnaUon that can be changed via an IVR function (eg. 
language). All data contained in the CC tables of the member profile database 
will be created, updated, and deleted by the CC. That is. the CC has the 
master version of these tables. A copy of new, updated, or deleted records 
will be sent to the transaction processing kernel so that the corresponding 
tables in their member profile database can be maintained. 



• Process member profile updates 

Member profile updates will be received in reward system or batch 
from the customer service centre (eg. name, address) or the IVR (eg. 
language) or transaction processing kernel (eg. from white mail processing). 
The CC will record these transactions in the MEMBER TXN table, validate 
the changes and update its member profile table. It will forward these changes 
10 the transaction processing kernel to update their member profile table and 
will also update the debit platform if required. 



• Process member profile retirements or suspensions 

The customer service centre can initiate retirements or suspensions at a 
member's request or the CC can determine that a member should be retired or 
suspended based on account inactivity or fraudulent use of the system. The 
CC will record these transactions in the MEMBER TXN table. It will forward 
these updates to the transaction processing kernel to update their member 
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profile table. The CC will also apply these changes as deletes to the 
CARD NUMBER table in the debit platform database. 

• Forward miscellaneous fulfillment requests to the transaction 
processing kernel 

Fulfillment requests will be created for welcome kits, replacement 
cards, program or partner information, and account statements. These requests 
will come primarily from the CSC. 

• Forward any member number based data collection to the online 
analytical processing system for analysis 

This type of information will be from survey responses or member 
comments that were collected in the IVR or by the CSC. A member's 
demographic information (eg. number of cars) may also be collected via the 
IVR or CSC. These two types of information will not be stored in the CC 
member profile table but will be transmitted to the transaction processing 
kernel to be stored in their data warehouse. The type of information collected 
may vary so a flexible process needs to be developed to handle this data 
transfer. 



Member Toward Transarti^ 

• Receive member reward transactions from the online analytical 
processing system 

Initially there will be a batch process for transmission of this data. 
These rewards are derived from member purchases from partner point of sale 
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systems. The reward, with purchase information, is captured in the 
MEMBER_REWARD_TXN table for audit purposes and for the CSC 
interface so that an agent can explain to a member bow they earned their 
units. After the transactions are added to the table, they are summarized by 
5 member number and the member's balance is updated with the reward on the 

debit platform CARDNUMBER table and on the CC member profile table. 



15 



• Receive member reward transactions from the Customer Service 

Centre 

These rewards are generated when a CSC agent gives a member units 
because of a problem they experienced. They are sometimes associated to a 
particular partner if the member's concern relates specifically to a partner. 
The reward is captured in the MEMBER_REW ARDTXN table with the CSC 
agent's id for audit purposes and for queries by the CSC. Immediate reward 
system update to the member's balance on the debh platform 
CARD_NUMBER table is required. The member's balance on the CC 
member profile table is also updated. 



20 



• Receive member reward transactions from the debit platform 
Reward transactions will be received from the debit platform for 
member to member transfers of units, branded messages, and - survey 
completion. These rewards have already been added to the member's balance 
in the CARD NUMBER table but need to be added to the member's balance 
on the member profile table. They also need to be captured in the 
MEMBER_REWARD_TXN table for audit purposes and for queries by the 



CSC. 
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• Transaction audit trait 

The CC system should be able to track all transactions and if necessaf 
re-process any transactions that were not processed successfully. The system 
should also be able to reverse any transactions that were sent in error (backif 
out a reward from a member's balance if necessary). 



* Report any errors/anomalies 

As reward transactions are processed, they will be validated and 
analyzed for errors such as unknown member number or "large" reward, etc. 
A facility will be provided to review and correct any errors/anomalies and 
resubmit the reward transaction for processing. 



• Send member reward transactions to the online analytical processing 

system 

Online analytical processing system will need a copy of reward 
transactions for rewards that were not generated by purchases (eg. units 
awarded by the customer service centre or from a survey) so that the 
information is available for statementing, billing, and analytics. This 
information will be sent in a batch process. 

Member Consumption Tran^tf^ 



• Receive member consumption transactions from the debit platform 

Member consumption transactions will be generated by the debit 
platform for outbound calls that consume a member's units. The member's 
balance on the debit platform CARD_NUMBER table has already been 
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updated but the member's balance on the CC member profile table needs tole 
updated. The consumption information is captured in the 
MEMBER_CONSUMPTION_TXN table for audit purposes and for the CSC 
interface so that an agent can explain to a member how they used their units. 



• Receive member consumption transactions for transfers 

A member to member transfer will generate a reward for one member 
and a consumption for the other. If this transaction originates from the debit 
platform then both members* balances on the debit platform have already bea 
updated but the members* balances on the CC member profile table need to fc 
updated. U this transaction originates from the CSC then the members* 
balances need to be updated on the debit platform CARD NUMBER table anf 
on the CC member profile table. This transaction will be captured in the 
MEMBER_CONSUMPTION_TXN table for audit purposes and for queries * 
the CSC. 



• Send member consumption transactions to the online analytical 
processing system 

A batch process will extract and send the member consumption 
transactions to the transaction processing kernel so that the inforraadon is 
available for statementing and analytics. 



20 • Transaction audit trail 

The CC system should be able to track all transactions and if necessarj 
re-process any transactions that were not processed successfully. The system 
should also be able to reverse any transactions that were sent in error (backing 
out a consumption from a member's balance if necessary). 
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• Report any errors/anomalies 

As consumption transactions are processed, they will be validated and 
analyzed for errors such as unknown member number or "large" 
consumption, etc. A facility will be provided to review and correct any 
errors/anomalies and resubmit the consumption transaction for processing. 



• Forward a list of valid branded message codes to the online 
analytical processing system 

Once a branded message has been recorded and setup on all the IVR 
nodes and a code has been assigned to uniquely identify the message, it will 
be sent to transaction processing kernal so that members can be assigned to 
listen to the message. The information about a branded message is stored in 
the CC BRANDED_MESSAGE table. 



• Accept from online analytical processing system member message 
1 5 assignments 

A batch file containing a list of targeted member numbers with a 
corresponding branded message code and priority win be sent from the 
transaction processing kemal to the CC. As the CC processes this file, it will 
add the member number and branded message code combination to the 
20 MEMBERMESSAGE table. There is a need to queue many messages for a 

member but to only play one per call. The member message table is 
essentially the member's queue of messages from which the debit platform 
chooses the next message to be played to the member during their call into tbs 

ivr. 
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• Funnel member message information back to online analytical 
processing system 

When a branded message has been listened to by a member, either 
partially or rully, a record is created in the message transaction table 
(MES S AGEJTXN) . This table records the date and time that the message was 
listened to and how much of the message was listened to by the member 
(number of seconds). A batch process will extract and send member message 
information to transaction processing kernel for "listened to" messages. 



• Record and apply rewards (if applicable) for fully listened to 



• Automatically expire branded messages after a preset date 



• Cancel branded messages at any time 

Member messages can be canceUed either specifically by member 
number or globally like the expiry. 



15 Sl HTgys for Interactive fl»m ffi ) 



♦ Forward a list of valid survey codes to online analytical processing 



Once the survey or interactive game has been developed and setup on 
all the IVR nodes and a code has been assigned to uniquely identify it, it will 
be sent to transaction processing kernel so that members can be assigned to 
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the survey. The information about a survey is stored in the CC SURVEY 
table. The call flow position field in this table will determine where in the call 
flow the survey can be offered. 

• Accept from online analytical processing system survey assignments 

A batch file containing a list of targeted member numbers with a 
corresponding survey code and priority wilt be sent from transaction 
processing kernel to the CC. As the CC processes this file, it will add the 
member number and survey code combination to the MEMBERJSURVEY 
table. There is a need to queue many surveys for a member but to only play 
orie per call. The member survey table is essentially the member's queue of 
surveys from which the debit platform chooses the next survey to be played to 
the member during their call into the IVR. 

• Funnel member survey information back to online analytical 
processing system 

When a survey has been fully completed by a member a record is 
created in the survey transaction table (SURVEY_TXN). This table records 
the date and time that the survey was completed. A batch process will extract 
and send member survey transaction data to the transaction processing kernel 
for completed surveys. The survey responses will be sent to the transaction 
processing kernel through a separate process as this information will vary 
depending on the design of the survey. 

• Record and apply rewards (if applicable) for successfully completed 
surveys 
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* Automatically expire surveys after a preset date 

• Cancel surveys at any time 

Member surveys can be cancelled either specificaHy by member 
number or globally Jifce the expiry. 

fraud Detect inn 



• Provide system alarms and procedures to detect and deal with 
fraudulent card use. 



• Manage the reward system call detail records on the debit platform 
If this information is required for analytics, then extract it and send it 

to the transaction processing kernel. A history will be maintained for billing 

purposes as well as for telecommunications analytics. The CC will control the 

archiving of the cdr information from the reward system 

CONSUMER_CA1XLOG and CONS_OUTBOUND_LOG tables on the debit 

platform. 



• Provide information and reports that can be used to optimize 
telecommunications 

Reports will be available to analyze the system usage and capacity 
requirements with regards to call volumes and peak periods. These reports 
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will be used to optimize all aspects of the telecommunications from 800 
number translations through to the Summa and DirectTalk. 
Telecommunications reporting will also analyze the batch and reward system 
transaction processing of the CC. 

5 Numerous modifications, variations, and adaptations may be made to 

the particular embodiments of the invention described above without departing 
from the scope of the invention, which is defined in the claims. 
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CLAIMS: 

1. A method of providing telecommunications rewards to a 
member comprising the steps of: 

generating a point-of-sale transaction; 

5 relating the point-of-sale transaction to a member of 

telecommunications awards; 

determining value of reward in dependence upon the point-of-sale 
transaction; 

updating a member's profile for the member by the value determined. 

^ 0 2. A method as claimed in claim 1 wherein the step of generating 

a point-of-sale transaction includes the steps of scanning a UPC code card of 
the member, and looking up the UPC code in a UPC database. 

3. A method as claimed in claim 1 wherein the step of determining 
value of the point-of-sale transaction to a member includes the step of 

15 referring to the member's profile and a rewards fiJe. 

4. A system for providing telecommunications rewards to a 
member comprising: 

a data collection system; 

a customer service centre; 

20 enrollment processes; 
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a transaction processing system for managing data from tbe point-of- 
sale collection system and members and for calculation of rewards; 

a control center for processing system transactions for tbe customer 
service center, system access, debit platform management and enrolling 
processes. 
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A data processing system for implementing 
transaction management of auction-based trading 
for specialized items such as fixed income in- 
struments. The data processing system provides 
a highly structured trading protocol implemented 
through a sequence of trading paradigms. Once 
properly formatted (130) on-line market data (115) 
is transmitted for determination for a real time com- 
mand selection (140), then loaded into a security 
database (160). System proprietors in automated 
options and futures processing (170 and 180) obtain 
data for quantifying and evaluating positions pur- 
suant to trading option and futures contracts on indi- 
vidual securities. The distribution for securities data 
to the data accumulators and vendors (190) is fol- 
lowed by continual distribution of securities data to 
traders within investment community (200), the sup- 
port of automated trading (210) and finally declaring 
and reporting functions associated with such trad- 
ing including clearance operators (220), The sys- 
tem employs a distributed computer processing net- 
work linking together a plurality of commonly pro- 
grammed controlled workstations. The protocol and 
its programmed controlling logic enhances trading 
efficiency, rewards market makers and fairly dis- 
tributes market opportunity to system users. 
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Automated Auction Protocol Processor 



Field of the Invention 

The present invention relates to data processing systems for assisting in 
financial transactions. More particularly, the present invention relates to a data 
processing apparatus and method for the managed trading of select classes of 
securities or other commodities in accordance with specific protocols in an 
auction format with controlled sequence of auction events. The inventive 
system is presented in the context of selected fixed income auction protocols for 
fairly and quickly transacting offer-bid trading. 

Background of the Invention 

Economic activity has at its centerpiece the buyer-seller transaction for all 
goods and services produced and consumed in a market economy. It is the 
fundamental mechanism to which resources are allocated to producers and 
output to consumers. The operation of the buyer-seller mechanism can and 
often is a critical determination of economic efficiency and when operated 
properly, will substantially enhance market performance. 

Through history, there have been many different approaches adopted to 
fairly bring buyers and sellers together, each with the key objective of 
permitting transactions at or as close as possible to the "market" price of the 
goods. By definition, the market price is the price (in given currency terms) 
that a fully educated market, given full access will transact select goods. This 
can only be accomplished by permitting full access to the transaction by 
essentially all potential buyers and sellers. However, the buyer-seller 
transaction must be structured to operate at very low costs - or it will distort the 
market price of goods with the artificially high transactions- costs. Thus, as can 
be seen, the two keys to effective buyer/seller transactions - full access and 
knowledge coupled with low costs - can be and are often conflicting, 
necessitating trade-offs between trading efficiency and market knowledge. 
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One well-known and particularly successful trading system is known as 
the "open outcry auction". This involves a process wherein buyers and sellers 
collect in one location and prices for select goods are presented to the group 
through a broker, via simple vocal offerings. This approach has been used for 
almost all kinds of goods, but is particularly useful where there are no 
established trading locations or markets for the selected items. It is the 
dominant trading forum for exotic items such as rare pieces of art and the like. 
Although successful in bringing interested parties to the transaction, the overall 
process can be very expensive, adding significantly to the market-distorting 
transaction costs. 

Open outcry auction techniques, modified over time, have also found 
successful application in many commodity trading activities, including the 
buying and selling of farm produce and livestock, oil and commodities contracts, 
future contracts on a variety of items and - particularly germane to the present 
invention - fixed income securities. These trading activities focus on the buying 
and selling of essentially fungible items, that is, items that are without 
meaningful differentiation from like items on the market. For example, a bushel 
of wheat for February delivery is considered for sale and delivery at a price 
independent from its source. Similarly, a 30-year treasury bond paying a 
coupon rate of 6.75 percent and having an August 1996 issue date is 
indistinguishable from other 30-year treasuries having the same properties. 
Accordingly, the price buyers are willing to pay and sellers willing to accept 
defines the market price of all 30-year treasury bonds of that same vintage, 
allowing a source transparent application of open outcry auction trading. 

The fixed income securities issued by the United States Government are 
known as U.S. treasuries. These instruments typically span maturity terms at 
issue of 13 to 52 weeks (T-bills), one to ten years (notes), and up to 30 years 
(bonds). The T-bills are pure discount securities having no coupons. Almost all 
other treasuries having longer terms are coupon notes or bonds, with a defined 
payment cycle of semi-annual payments to the holder. 
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Treasuries have characteristic properties that make them especially useful 
for the purpose of the present invention and, therefore, are used exclusively in 
the following discussions with the fundamental tenant that the principles may be 
applied to other types of fixed income securities without departing from the 
inventive concepts. One important attribute of treasuries, in the context of the 
present invention, is the minimal and uniform default risk; the issuance of U.S. 
government paper removes the default risk as a defining criteria in the relative 
pricing of treasuries in the market place when they are backed by the full faith 
and credit of the U.S. government. 

New treasury securities are auctioned by the U.S. government at pre- 
established auction dates. The auction prices for the treasuries having a face 
value with a set coupon rate will define the issuance yields of the security. 
After the auction, the treasuries enter the secondary market and are traded 
typically "over the counter", i.e., without a defined exchange. As inflation 
expectations and supply and demand conditions change, the prices of the 
recently auctioned treasuries fluctuate on the secondary market. These new 
prices are reflected by competing bid and ask prices communicated among 
institutions, banks, brokers, and dealers in the secondary market. For example, 
the yield of a treasury note increases as its price drops in the market, typically 
reflecting an overall increase in the interest rates for that term of security. 

The newly auctioned securities are traded with and in conjunction with 
the securities issued in earlier auctions. In this context, some securities are 
traded more often than others and are called the "actives"; the actives usually 
correspond to the recently issued securities as opposed to the older securities in 
the market. Indeed, some older securities are infrequently traded, creating an 
illiquid market that may or may not reflect the current market-determined 
interest rate for that maturity length security. 

As can be realized by the foregoing description, the very size and 
diversity of the treasury market implicates an unprecedented level of 
sophistication by market participants in the bidding, offering, buying, and selling 
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transactions involving these securities. The very complexity associated with the 
transactions and the scale of trading undertaken by banks, brokers, dealers and 
institutional participants necessitates a rigidly structured approach to trading. 

In the past, open outcry auction bond brokering has served its customers 
well, providing highly efficient executions at near perfect market pricing. The 
open outcry auction applied to bond trading was implemented by a broker 
working with a collection of customers to create and manage a market. 
Typicalcustomer representatives - both buyers and sellers - at a common 
location (e.g., a single room) where the representatives of the customers would 
communicate with each other to develop pricing and confirm transactions. This 
process employed the expression by the representatives of various bid and offer 
prices for the fixed income security at select volumes (i.e., how many million 
dollars of bonds at a given maturity). This expression would involve the loud 
oral "cry" of a customer-proposed bid or offer and the coordination with the 
fellow representatives regarding the extraction of complimentary positions - until 
a transaction match is made and a deal is done. This "trade capture" process 
relies on after-the-fact reporting of what just transpired through the oral outcry 
trade. 

Recently, the trade capture process was performed by having designated 
clerks input data into electronic input devices. An input clerk would attempt to 
interpret the open outcry of many individual brokers simultaneously who 
sequentially are making verbally known their trading instructions of their 
customers. The quality of the data capture was a function of the interpretative 
skill of the input clerk, and the volume and the volatility of customer orders. A 
significant drawback to this type of auction data capture process is the difficulty 
in discerning the distinct trading instructions verbalized in rapid succession 
during a quickly moving market, so that an accurate sequence of data can be 
captured by brokers and a set of inputters. 

The many permutations of this process will be discussed in some detail 
below. At this juncture, suffice to say that at the volumes of business 
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transactions existing at the time of its development, and the lack of suitable 
alternatives, left this process as the dominant trading mechanism for decades. 
However successful, this approach was not perfect. Indeed, in recent years, 
some of the problems in a open outcry auction forum have been amplified by 
the vastly increased level of trading now undertaken in the fixed income field. 
Without attempting to be comprehensive, difficulties would occur by the 
injection of trader personalities into the open outcry auction process. For 
example, a loud, highly vocal representative may in fact dominate trading - and 
transaction flow - even though he/she may only represent a smaller and less 
critical collection of customers. Although such aggressive actions at open 
outcry auction may be beneficial to those particular customers in the short run, 
overall, such dominance of the trading can and will distort pricing away from 
the actual market conditions. 

Other problems exist in open outcry auction that deplete efficient trading. 
The speed at which trading flows and the oral nature of the auction process 
injects a potential for human error that often translates into many millions of 
dollars committed to trades unrelated to customer objectives. As such, the 
broker is left at the end of each trading day with a reconciliation process that 
may, under certain market conditions, wipe out all associated profit from that 
day's trading. Also, customers may quickly change direction regarding trading, 
based on new information available to the market. Shifting position or backing 
out of previously committed transactions on very short notice is often very 
difficult in the traditional open outcry auction process. 

There have been many past efforts to incorporate computers into trading 
support for select applications and securities. Indeed, almost all trading today 
involves some computer support, from simple information delivery to 
sophisticated trading systems that automate transactions at select criteria. 
However, these systems have not significantly impacted the issues presented 
above as they relate to open outcry auction trading in the fixed income field. It 
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was with this understanding of the problems with certain trading processes that 
formed the impetus for the present invention. 

Summary of the Invention 

It is, in view of the foregoing, an object of the present invention to 
provide a data processing system to implement a trading system capable of high 
volume trading activity. 

Another object of the present invention is to provide a data processing 
method supporting a transaction enabling process for trading securities at 
accelerated levels with minimal errors and costs. 

It is yet another object of the present invention to provide a data 
processing system to support a formalized trading protocol governing the control 
of trading on a bid/offer market. 

It is also an object of the present invention to provide a system for 
collecting, displaying and distributing in real time information on current market 
activity in fixed income securities and processing this information to quantify 
the extent of order and trading activity of customers in real time. 

It is another object of the present invention to provide an apparatus for 
the select processing of several types of data wherein data is qualified prior to 
use and translating the qualified data into order and trading states for fixed 
income securities. 

It is still another object of the present invention to provide a data 
processing system that provides controlled access to trading commands pursuant 
to pre-established trading criteria. 

It is yet another object of the present invention to provide a computer 
system that includes multiple workstations linked by a high speed 
communication loop to permit rapid distribution and exchange of market data to 
participating customers and brokers. 
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It is still another object of the present invention to provide a system that 
rewards customers that create liquidity while insuring customer orders are 
satisfied in an orderly and equitable fashion. 

It is yet another object of the present invention to provide a database 
system linked to the auction processor for collecting, filtering, and distributing 
select market data in near real time. 

It is another object of the present invention to provide a computer system 
with a dedicated input system for a workstation, that is customized for the 
trading undertaken by that workstation and may be customized to the trading 
patterns and customers for a given broker at that workstation. 

Yet another object of this invention is to provide timely order checkout. 
Still another object of this invention is to provide customized trading 
tools particular to a given customer, such as stop limit orders, contingent orders, 
flags (warnings) to the broker that a particular customer has reached a trading 
limit {e.g., margin limit), and the like. 

A further object of this invention is to utilize the present system for the 
trading of other financial products, such as futures, indices, commodities, 
securities, other options, and the like; in. general, any tangible or intangible 
property that would be amenable to purchase/sale by open outcry auction. 

The above and other objects of the present invention are realized in a 
specifically delineated computer-based, data processing system having a 
governing program controlled logic for orchestrated management of select 
trading functionality. The data processing employs a plurality of trading 
workstations linked with a server for coordinated data flow and processing. 
Communication is provided by perse available network, via Ethernet, token 
ring, token bus, or other hierarchical LAN and/or WAN configuration. The 
system preferably includes a dedicated keypad for input from each workstation 
that facilitates providing individually programmed keystroke commands; other 
keyboards or keypads can be used and are often software configurable so as to 
be compliant with the present system. A central processing logic dictates the 
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available trading options and screen displays for each workstation. As 
transactions are entered, various protocols effect the allocation of bid-offer 
control and trade management. As trades are completed, the system updates a 
linked database with the newly entered transactional data. 

In accordance with the varying aspects of the present invention, the 
controlling logic provides for a particular sequence of trading states for each 
participant. The five states are: 

TABLE I 

(i) Workup State 

(ii) Bid-Offer State 

(iii) Second Look State 

(iv) When State 

(v) Workdown State 



As the various transactions are entered, the trading stations and their 
interrelationships exist in one of these five states. The workstation "state" will 
determine the options available to that trader - and thus enables controlling the 
flow of trades in a cost-efficient and error-free manner. As all participants 
implement trading on similarly configured workstations, the protocols are 
universal for all traders, thereby precluding aggressive control of transactions in 
the absence of true capital commitment. 

The foregoing features of the present invention may be more fully 
appreciated by review of specific illustrative examples thereof, presented 
hereinbelow in conjunction with a descriptive set of figures. 

Brief Description of the Figures 

Fig. 1 is a system block diagram depicting the salient hardware 
components of the present invention; 

Fig. 2 provides a flow diagram depicting the transmission of trading 
related information; 
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Fig. 3 depicts the salient features of the dedicated keypad; 
Fig. 4 is a block diagram of the various system states and pathways 
therebetween; 

Fig. 5 is a logic diagram for trading data input; 
Fig. 6 is a logic diagram for the Bid/Offer State; 
Fig. 7 is a logic diagram for the When State; 
Fig. 8 is a logic diagram for the Workup State; 
Fig. 9 is a logic diagram for the Second Look State; 
Fig. 10 is a logic diagram for the Workdown State; and 
Fig. II is a trading logic summary table. 

Detailed Description of Specific Embodiments of the Invention 

In brief overview, the present invention is directed to a data processing 
system for implementing complex trading rules in support of select transactions. 
The first aspect of the invention relates to a particular hardware arrangement 
that provides a specifically tailored platform for processor enhanced and 
supported trading. This hardware arrangement encompasses a plurality of 
custom designed workstations linked together for communication. Each 
workstation is linked to a central server that orchestrates the trading processes in 
accordance with program controlled logic. The workstation includes a display 
for presentation of the particulars of trading activity. A customized keypad 
permits enhanced data/position entry by the broker. 

The second aspect of the invention is the governing logic for controlling 
system dynamics. This logic is stored in system memory and provides the 
sequence of protocols and rules that allocate trading priority, and the system 
responses to operative commands entered by the brokers at the workstations. 
The system logic is critical on two levels. First, it is important as the guiding 
principles underlying the system and thus performance is tied directly thereto. 
On a second level, system logic must be known to all customers and traders as 
the rules dictating market access and response - to eliminate any confusion and 



WO 58/26363 PCT/US97/22423 
10 

to place participants on as close to an equal footing as possible. It is a 
fundamental precept of the present system to provide fair and complete access to 
the trading process to all registered participants. 

To better appreciate the details of this invention, a review of the 
nomenclature employed herein is recommended. For purposes of illustration, 
the examples given in this application focus on fixed income instruments and 
trading of these instruments in large volumes - with the volume of a given 
transaction delineated in dollars (e.g., $25 million of 10-year treasuries). 

The following terms, and their associated definition, are used herein: 
TABLE 2 

B, d Dollar amount offered to buy a security - issue. 

Offer Dollar amount offered to sell a security - issue. 

Spread Difference between best bid(s) and offer(s) on market. 

Issue A common class of fixed rate treasuries. 

Hit Accepting a pending bid. 

Lif * Accepting a pending offer. 

Slze The volume in dollars of a particular Bid/Offer. 

Makers Customers with pending offers and bids - making a market. 

Uncleared Entry Current bids/offers that lack a counterparty, i.e., have not 
been lifted or hit. 

Traders After a trade is initiated, all customers involved in 

transactions (as buyer or seller). 
Trade A string of transactions at one price initiated by a hit or lift 

and continuing until timed out or done. 
Aggressor A customer who initiates a trade. 

Active Side Group of Traders on same side of market as the Aggressor. 
Passive Side Group of customers on opposite side of market from the 
Aggressor. 
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The genera! context of system operation is based on the repetitive 
operation of several functions, and, in its preferred embodiment, implements 
these functions through a specially designed keypad. Generally, the process 
begins when customers contact the brokers and place bids and offers for a 
defined class of instruments. These various positions are displayed on the 
computer terminal in specific ways to reflect priority, etc. A customer can 
establish trading priority by placing a bid or offer at a select price and volume; 
bids at the same price are displayed on the screen in time order in which they 
enter the system (as are offers). As such a "queue" of bids and offers develops, 
with place in line set by time at the same price. This queue is displayed on 
screen at the broker's workstation. Typically, there is a small difference 
between the bid price and offer price - the "spread". If no difference exists, this 
is known as a "locked" market. 

Importantly, a bid and offer are commitments - once placed, a bid can be 
"hit" and an offer can be "lifted" by a customer willing to trade the instrument 
at the set price. 

To control trading between many participating customers, some level of 
hierarchy is set. A customer who hits on a bid or lifts an offer is promoted to a 
new level known as the "aggressor". By acting on a bid or offer, the aggressor 
defines (and thus establishes) the active side of the trade. For example, if the 
customer hits a bid, selling becomes the active side of the trade and buying 
turns passive. However, if the customer lifts an offer, buying is active. This is 
an important practical consideration, as by convention the active side pays 
commissions on the ensuing transactions. This allocation of commissions is 
premised on the notion that the active customers are taking advantage of 
liquidity - while the passive side is supplying liquidity to the market. 

For controlled implementation, the above-noted delineation between 
active and passive sides is important and carries more significance in processing 
transactions than the different sides of the transaction, i.e., the bid and offer. 
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Focusing further on the nomenclature for the system logic, a "trade" is 
considered a sequence of trading events, triggered by the initial hit or lift that 
defines the aggressor, and continues for all such transactions until the trade 
"clears". During a trade, the aggressor side remains active and all transactions 
take place at the price set by the initial hit or lift - regardless of the number of 
following transactions. To properly track transaction activity, a trade generates 
a (virtual and/or real) single trade ticket, with an associated, preferably screen- 
displayed, reference number, and can additionally generate several trade tickets 
each one reflecting the total size of the transaction per customer per side. 

In view of the foregoing, attention is first directed to Fig. 1, a block 
diagram depicting various hardware components found in an operative 
embodiment of the present invention. In this context, a plurality of workstations 
10 are provided, each individually linked to a central server by network lines 15. 
Server 20 cab be controlled by software for managing the interaction of the 
individual workstations 10 in accordance with system constraints. 

Continuing in Fig. 1, the system may be linked to brokers and customers 
at remote locations. Access to trading activity is accomplished to 
Communication Server 30 and Remote Server 40 to a remote distributor hub 50 
and remote workstation 60. Supplemental communication lines are utilized via 
conventional phone link 90. The above platform further includes a 32-bit 
operating system to manage the multi-tasking environment within the network. 
The present invention has been successfully implemented using the OS/2® 
operating system; however, other operating systems may be substituted. The 
workstation design can be selected from Pentium* processor based PCs, SPARC 
Station® (using UNIX®) or other microprocessor based systems. 

Now turning to Fig. 2, the overall information paths of the present 
invention are presented in block diagram form. This market information is 
derived from the auction process and is a highly valuable source of data to 
related markets (futures and options, or cash, as the case may be). Beginning 
with block 100, market data is collected from the plurality of on-line terminals 
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operated by brokers within the relevant bond market sector. A continual 
exchange of information, flows between the brokers, depicted in block 100, and 
the system proprietor, block 110, i.e., as bids, offers and trades are transacted in 
real time. This information is collected by the system proprietor and entered 
into the data processor database. 

On-line market data is then transferred to the data filter and enhancer 
module, block 115, which acts to clarify and articulate the continuous incoming 
market data for use, e.g., by data accumulators, block 120. One aspect of the 
data enhancer operation will be the conversion of on-line trading information 
into digital form for transmission to the classification processor, block 130. The 
operation of the classification processor is directed to creating a data set in 
proper format for further manipulation. This includes the generation of a 
coordinated array of data in matrix format. 

Once properly formatted, the on-line market data is then transmitted to 
the qualification processor, block 140, for determination for a real time 
command selection. The information is then loaded into the security database, 
block 150, and then passed to the distribution processor, block 160. 

The foregoing operation will result in the real time distribution among 
brokering stations for decision execution and for select distribution within the 
fixed income investment community. In the context of the present invention, 
three segments of this community are provided with the data. At block 180 and 
block 170, system proprietors involved in automated options and futures 
processing are provided the securities data for quantifying and evaluating 
specific options and futures positions pursuant to the trading of option and 
futures contracts on individual securities. In a similar manner, the securities 
data is provided to system proprietors regarding options and futures contracts to 
permit proper transactions in the trading of options and futures contracts based 
on the individual securities data. 

The third channel of distribution for the Securities data is to the data 
accumulators and vendors at block 190. This is followed by the continual 
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distribution of the securities data to traders and brokers within the investment 
community, block 200, the support of automated trading, block 210, and finally 
declaring and reporting functions associated with such trading, block 220, to 
include clearance operators among others. 

The trading activity is highly fluid and fast paced. Accordingly, efficient 
input systems are important to effectuate the multiple options and the use of a 
highly specialized keypad that permits these levels of efficiency in the present 
context. Accordingly, a separate aspect of the present invention is the unique 
keypad depicted in Fig. 3. 

During processing, various "states" are reached, depending on the type of 
inputs received by the system. The core state of "Bid-and-Offer" reflects the 
open status of the market. In this state, customers are referenced as "makers" 
and "contra-makers"; during all other states, customers are considered "traders" 
and "contra-traders". Under this notation, traders and makers are those 
customers that issue a trading command, while contra - makers and contra - 
traders are those who receive a trading command. Some participants in the 
Workup State, e.g., the first buyer and/or fist seller, are known as "current 
workers" and are vested with the authority under system control to hold up a 
trade for a predetermined duration of time. Important character distinctions 
between customers at various stages of trade processing are displayed to the 
broker on screen by reverse highlight or similar attribute. 

The interrelationship of these five system "states" is depicted in Fig. 4. 
Initial trading is always predicated on the Bid/Offer State, 400, with the 
sequence process, 420, assessing system inputs for a change of current state. As 
inputs are entered, a state change is triggered and processing shifts to the 
paradigms associated with (i) When, (ii) Workup, (iii) Workdown, and (iv) 
Second Look. As each state is entered, the protocols are shifted and new rules 
to trading apply. 

Information about trade progress and participants are provided at each 
workstation in the form of a specifically oriented screen display. In particular, 
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the system provides for screen display in the form of a trading quadrant or 
"quad" wherein key trading indicators are displayed. A sample QUAD is 
depicted below: 
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In the above QUAD, the current bid is depicted adjacent and above the 
CUST designation - reflecting a bid price of "100.01"; continuing on the same 
line, the current offer price is set at "100.03" - indicating a spread of .02. When 
a trade is in progress - as initiated by a hit or lift from the Bid/Offer State, the 
broker's attention is mainly directed to the conditional prompt showing the total 
size that is being bid or offered and that can be acted upon by the participating 
customers. This number is displayed at the intersection of the totals line and the 
Bid/Offer column. This total is further refined in the quad into individual 
prequantities, indicating the customer sizes in their respective rows. 

Above the BOT and SOLD captions in QUAD 1, a second totals counter 
provides the Makers total to the broker. In the Bid/Offer State this total is the 
same as the conditional prompt as there are no executions. This changes after 
the first transaction when a "traders list" is created - and the conditional prompt 
tracks the traders total, while the Maker's total keeps track of the quantity left in 
the Maker's list. 

Turning now to Fig. 5, the data selected for display on the QUAD is 
processed in accordance with depicted logic. The system enters a new 
CUST(ID), block 520, e.g., "2001" and stores this in active memory with 
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associated trade data/command TRD(ID), block 530. The trading command is 
- confirmed at a systems level, i.e., rejecting system errors via Alarm, at 550. 
Once confirmed, the new data/command TRD(ID) is distributed to the screen 
buffers for the associated work status for display, block 560. This is repeated 
for each new entry, block 570. 

The following discussion now focuses on the Bid/Offer State, wherein 
market makers are inputting various bids and offers into the system while 
waiting for an execution as the market matures. These pending commitments 
may be taken via hit or lift by makers currently showing or by a third party 
without showing its position prior to the hit (or lift). As new bids and offers are 
made, the price attendant therewith determines the placement in the queue, with 
equally priced offers (or bids) ordered in time entry. Accordingly, as the market 
tightens with better bids and offers (reducing the spread), these new positions 
are moved to the top of the queue as displayed. 

In addition to price, bids and offers include a size component, that is used 
to express the dollar volume of the pending bid (or offer). For a customer to 
increase the size of the bid or offer, a new entry is made, and placed into the 
queue separately as the system will not increment the size component - unless 
adjacent to an existing Bid/Offer already in the queue. In this way, as bids and 
offers are entered during this state, they are displayed to the brokers in relation 
to their respective size, with the total Bid/Offer count (aggregate size) displayed 
at the above noted conditional prompt. As such, the conditional prompt serves 
as the main impetus for a transaction due to its measure of apparent market 
capacity at a given price. 

A Bid/Offer is typically entered as "uncleared" during the Bid/Offer 
State, indicating that the bid or offer is only available to the current market 
participants, i.e., those on the list with current commitments (bids/offers). 
Accordingly, uncleared presentations are seen on the screens of only these 
participants for a system set time interval - and only those customers with 
current participation can lift or hit these uncleared entries. After the preset time 
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interval has run (tracked by system internal clock) the uncleared bids - if still 
extant - become available beyond the current participants. There is a business 
purpose for this arrangement. By allowing customers with active bids/offers the 
first view of the new entry, this rewards these customers for showing the 
market on their side. Thus the initially bidders are invited to become 
Aggressors - and the system preset interval provides these bidders time to make 
their decision by preventing new buyers and sellers from entering into the 
market for this discrete interval. 

The system logic associated with the Bid/Offer State is depicted in logic 
flowchart form in Fig. 6. Logic conceptually begins at block 600, with the 
data/command entry at block 620. The State Selector qualifies the State as 
Bid/Offer, block 620. At block 630, the CUST_X profile is taken from the new 
entry and all associated data passed into a parameter string, block 640, which is 
entered. 

Continuing with this logic path, test 650 compares any Bid/Offer pricing 
associated with TRD(ID) to then pending bids and offers to discern whether the 
new entry improves on current pricing; if not better, logic branches to block 690 
and the new entry is placed at the end of the queue, Q-end. However, if the 
new pricing, PRL(ID) is better than the old (then current) pricing PRC(OLD), 
logic brings the new CUST_X to the top of the queue, block 660; also, the 
market is locked allowing only, the current makers (displayed) to react to the 
new pricing for a pre-set time, block 670. 

At test 700, system checks for a new hit/lift; if none, logic continues to 
the next entry, block 710. A position response to Test 700 shifts processing to 
the next state, block 720. 

The screen display will change according to the various entries into the 
bidding process. In QUAD 2 depicted below, customers 3001 - 3003 on the bid 
side reflect a market of 27 million; see conditional prompt: 27. This includes a 
first bid by customer ("CUST") 3001 of 5.0 million, followed a little later by a 
second bid of 20 million. In this example, CUST 3007 (could be a bank or 
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other institutional participation) has entered the picture with an uncleared offer 
of 10 million (marked by asterisk - indicating offer is uncleared); this is the 10 
million depicted on the conditional prompt line on the offer side. As such, ' 
controlling logic gives the original makers the first review of the new offer by 
3007. After the interval, the market is again opened. 
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The When State is triggered by a trading command against an uncleared 
Bid/Offer by an Aggressor who is not one of the original makers. However, the 
system controls will not allow this trading command by the new Aggressor to be 
instantaneously executed. In accordance with system logic, the trading 
processor creates a time interval or delay, and thereby provides the original 
Maker(s) time to assess the new situation created by the Aggressor by 
permitting response to the uncleared entry on the passive side. 

In particular, as noted above, the uncleared status exists for a defined 
interval - controlled by computer driven timer. It is only during this interval 
that a When State can be instituted, which can then only last until resolved by 
either the action of the original Makers on the passive side, or by the expiration 
of the interval timer within system logic. 

During When State processing, the system displays the original Makers - 
existing with Bid/Offers outstanding prior to the entry of the new Aggressor - 
and the new Trader(s) entering via hit or lift commands on the pending 
uncleared Bid/Offer; these Makers and Traders are clearly separated on the 
screen. (See QUAD 3B below). Importantly, these original Makers are given 
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the opportunity to trade at the new price point established by the Aggressor; 
multiple makers from the. original list will each have access to take the new 
price in the order of their priority in the queue. The system will increment 
through each Maker; if one issues a buy/sell order at their size, they become the 
Aggressor. If this occurs, the logic departs the When State and can either enter 
the Workup State or Workdown State depending on whether the new Aggressor 
takes the entire volume indicated at the conditional prompt. 

Once When State processing has been initiated, no trader entries from the 
passive side are permitted and customers are blocked from entering on the active 
side, if they represent the only customer input from the passive side previously. 
Entries on the uncleared (active) side will come from new traders, extant 
traders, or the original makers which drive the system back to the Bid/Offer 
State preceding a trade. If, for example, a trade has 10 offered and 5 are "up", 
during the When State the trader preferably can cancell the amount which is not 
yet committed. 

However, if the second interval timer expires without any intercession by 
the original Makers, the When entries (one or several) will automatically trade - 
and the original Makers will not part take in this trade. During the interval, 
WTAK flashes on screen to the Makers showing a take on the uncleared offer; 
WHTT will flash for a hit on an uncleared bid. During this interval, the size 
entries for pending Makers are all initialized to zero, and no longer -presented at 
the conditional prompt. 

When State processing is depicted in Fig. 7 and is triggered by a trading 
command CMD(I), block 810, Test 820 confirms that the new trading command 
(hit or lift) is from a new Aggressor; if not, logic continues to block 880 and to 
either Workup or Workdown State. 

However, a positive response to Test 820 branches logic to block 830, 
wherein the market is locked for a pre-set time interval. At block 840, all then- 
current makers are reset to zero. At test 850, the system determines if these 
makers intercept the Aggressor before the time interval expires. If yes, the 
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intercepting maker becomes the Aggressor, block 860, with full control over the 
succeeding trade sequence. If not, the new Aggressor is set, block 870, and 
logic continues to the next State, block 880. 

The following sequence reflects the foregoing system logic; In 
QUAD 3A below, the Bid/Offer State has two customers, 3002 and 3003 each 
showing bids at 10 million; customer 3007 has just placed an uncleared offer for 
1 million. Customer 3001 wishes to lift the new offer by customer 3007 - but 
he can't automatically. In QUAD 3B below, customer 3001 attempts to lift the 
offer by customer 3007 forcing the system into the When State, and creates an 
uncleared list for the active side (bid here). However, the prequantity of the 
first two bidders is reduced to zero - as the system logic requires that these bids 
cannot be enforced at the new price point. In this example, the second interval 
timer provides both original Makers priority over customer 3001; with customer 
3002 retaining overall priority via its placement in the queue. 
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Transactions forming a trade take place in accordance with the present 
invention during one of two trading states, known as the Workup and 
Workdown States. The Workup state occurs pursuant to hits or lifts by an 
aggressor taking the entire inventory of volume shown on the passive side; once 
established, the Workup State gives exclusive rights to the trade to the initial 
trader - who the system recognizes as the current worker. On screen, current 
workers are highlighted in a defined manner known to other participants. 
Current workers control the trade and can submit additional transaction volume 
to their contra-traders; this to the exclusion of outside customers. Current 
workers on the active side of the trade will include the Aggressor, and possibly 
other traders, below the Aggressor with transactions that move the trade into the 
"Workup" State by filling residual volume that needs "Workdown". For the 
passive side, an Aggressor that takes the entire size limits current worker status 
to himself and his counterparty. 

The status of current worker dissipates upon entry of "done" by the 
broker, or the lapsing of the trading inactivity interval. Again, this interval is a 
pre-set system parameter triggered via system logic. Absent such termination, 
current workers can trade almost indefinitely, as long as they continue to 
respond to their corresponding size offerings. 

The Workup State logic is depicted in Figure 8 and is principally tied to 
size and new order data. The Aggressor size is entered as is the passive side 
prior to trade entry, blocks 910 and 920, respectively. At test 930, the system 
determines if the Aggressor has taken the entire market offering at time of trade; 
if "no" to test 930, logic continues to block 990 and ultimately the Workdown 
State (Figure 9). 

A positive response to Test 930 passes logic to blocks 940 and 950 
wherein the current workers are assigned and new trades entered. The system 
tests for new trades, Test 960, and processes these accordingly, block 970. This 
continues until the current workers are done or timed out, Test 980. 
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The above logic is better understood in the context of a particular 
example. As shown in QUAD 4A below, a typical opening Bid/Offer display is 
presented. 
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Assume the bid is hit by CUST 3005 selling the entire size ($16 million) 
to the passive side. This results in CUST 3005 as the Aggressor and the contra- 
traders (CUST 3001, 3002 and 3003) as the current workers. It is now the 
Workup State as the Aggressor has taken all initial size from the passive side. 
See QUAD 4B. 
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As a current worker, CUST 3002, wishing to continue, adds an additional 
5 million size (adding to CUST 3002's original 5 million), which is displayed as 
5 under Buy and 5 under BOT. See QUAD 4C. A new customer, CUST 3004, 
now offers 50 million. 
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QUAD 4C 
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New CUST 3004 must wait until the current workers are done (via 
keyboard entry or timer controlled system interval). Only after this, may CUST 
3004 clear the additional 5 million by CUST 3002, while leaving 45 million 
uncleared (see QUAD 4D). 
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As can be appreciated, various customer moves in the market are often 
fast paced - and on occasion position changes may occur almost simultaneously. 
An example of this may be a first customer hitting a second customer's bid of a 
certain size, via the buy /sell all key - an instant after that a second customer 
has significantly increased the bid size - say from S5 to $20 million. In this 
situation, the Aggressor, within the system, has now taken much more than he 
planned. This situation can be very disturbing in a rapidly shifting market. 

System logic addresses this problem by creating a supplemental state 
known as the "Second Look" State. If during processing, the passive side size 
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is increased just prior to a hit or lift command, the system discriminates the very 
recent offer/bid from the earlier entries, via an "age" timer, i.e., a system 
interval that tracks the pendency of all bids and offers and creates a Second 
Look State whenever a hit/lift (via buy/sell all key) occurs while a Bid/Offer is 
under, e.g., two seconds old. 

The Second Look, however, is limited. The Aggressor must complete the 
transaction excluding the new, i.e., "unaged" Bid/Offer. The new size is left 
uncleared and others may add more offers/bids on this, the passive side - but 
these stay below the line. Even though the Aggressor did not fill the entire size 
displayed, the Aggressor assumes current worker status and has the right to: 

1 Take the new size, creating the Workup State with 
the contra-trad ers; 

2. Refuse the new size; the Aggressor refusal (via 
"done" command) sets the trade into the Workdown 
State; and 

3. Take/hit a "partial" amount and then lose priority. 

The Second Look State is governed by the logic structure depicted in 
Fig. 9. In this arrangement, the trading command is entered - time stamped at 
block 1020. The extant passive maker entries are also entered, block 1030, and 
Test 1040 determines if the Passive side entries, PASS(ID) are "aged", i.e., not 
just entered. If yes, logic branches to Test 1090, to determine if the PASS(ID) 
is the last entry, PASS_END. If not, the next one is incremented with logic 
returning to the sequence start. 

A negative response to Test 1040 shifts logic to block 1050 wherein the 
new entry is parsed; the Aggressor is then given the opportunity to take the new 
size within the trade at Test 1060. If accepted, logic branches to Block 1080 
and to the Workup State. If negative, logic is shifted to the Workdown State, 
Block 1070. f 

These principles are delineated in the following sequence of screen 
displays in QUAD 5A below, wherein CUST 3001, 3002 and 3003 are showing 
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5mm, 1mm and 1mm, respectively. Just prior to the sell order by CUST 3007 
(HIT ALL), CUST 3004 enters with a 1mm size. All size transacts, except this 
late 1.0 mm as it had not "aged" sufficiently - as measured by system interval 
timer. This amount remains untraded and the system enters the Second Look 
State. 
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If CUST 3007 decides to fill this outstanding 1.0 mm size, the state 
moves out of "Second Look" and into the Workup State with CUST 3007 and 
CUST 3001 as Current Workers. 
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If, however, CUST 3007 passes, the trade goes to the Workdown State. 
New CUST 3005 is positioned below the line and can only trade after 
CUST 3001 is done and CUST 3004 trades. 



WO 98/16363 



PCT/US97/22423 



26 



QUAD 5C 



>7.625 225 




TZ Refno 68117 




108.04 


HIT 


7 


0 


Cost 


Buv 


BOT Cust Sell 


SOLD 


3001 


0 


5 3007 0 


7 


3002 


0 






3003 


0 


1 




3004 


1 


0 




3005 


1 


0 




TOTL 


1 


7 0 


7 



The final state for trading logic is known as the Workdown Sate and it 
occurs when the original Aggressor takes less than all of the size showing or the 
passive side. The remaining size must be worked down to complete the trade. 
This is to reward those customers that show bids/offers, their intent to buy/sell, 
and thus provide liquidity in the market. If the original Aggressor returns for 
the remaining size on the passive size, the Workup State is initiated. Another 
trader from the active side may "Workdown" the remaining passive side 
quantity and the trade will go to the Workup State - with this new trader as the 
current worker - if all the remaining size from the original Bid/Offer State is 
taken. 

The Workdown State allows new Aggressors to complete the uncleared 
bids on the passive side with logic conforming to the flowchart of Fig. 10. In 
this process, the Trading command, CMD(I), is entered at block 1210. At Test 
1220, the system confirms that the trade is for less than the total passive side, 
TOTL. If not, logic branches to block 1280 and is directed to the Workup 
State. 

A positive response to Test 1220 passes logic to block 1230 wherein the 
system opens trading to new Aggressors, to complete the pending passive side 
volume. However, no new passive side entries are permitted, block 1240, for 
the trade duration. Test 1250 confirms the last trade via timer Test 1260; if 
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either results in a "Yes", Workdown is terminated and the process returns to the 
Bid/Offer State. 

Importantly, new traders presenting on the passive side must wait until all 
the remaining original size is worked down - and their position is held below 
the line. This is depicted in the following screens. 
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In 

QUAD 6A, the Bid/Offer State is depicted with CUST 3001 showing a bid of 
$5 million. As the Aggressor, CUST 3001 lifts an offer from CUST 3007, but 
for only 5mm of CUST 3007 showing of 25 mm; leaving $20 million on the 
passive side. See QUAD 6B. 
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At this juncture, if CUST 3006 enters with $10 million offer, it must wait 
until the original passive side clears; CUST 3006 is thus kept below line as the 
remaining size is worked down. See QUAD 6C. 
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A trade is cleared when that price point engenders no further buyers or 
sellers. A "clear" button will resurrect a new Bid/Offer State, retaining original 
makers size from the active side - unless superceded, and remaining untraded 
size from the passive side. 

The logic associated with the five states discussed herein is summarized 
in tabular form in Fig. 1 1. The foregoing system design has resulted in a 
dramatic increase in efficiency and reduction in order errors on the trading floor. 

The often frenetic environment of trading, and the entry of commands on 
the preferred dedicated keypad shown in Fig. 3, and the human factor of 
customers changing their minds all contribute to the possibility that a trade has 
been made in error. More particularly, errors can arise due to incorrect entries 
into the system, a miscornmunication between a broker and trader, and the like. 
These errors can often force a "principal" broker into an unintended position 
during a trade. 

This invention preferably provides ways for the broker to effectively 
"undo" a trade, either by cancelling a pending order, or rolling-back executions 
during a trade state. As shown in Fig. 3, the keypad provides CANCEL, 
DONE, and UNDO keys to facilitate this process. The function of these keys 
when the system is in a particular state is described below, it being understood 
that the names given to these keys are arbitrary and any input means can be 
used to affect the desired action(s). 

In the Bid-Offer State, CANCEL functions to remove a maker's existing 
markets from one or more instruments in this one command stroke. 
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In the When State, CANCEL functions to remove a maker's markets only 
if there are no pending active BUY or SELL orders against it. Also, DONE 
functions to remove a potential aggressor, as weil as trade participants, from 
trading lists before orders are matched. 

During the Workdown State, CANCEL functions to remove any 
remaining passive maker's markets. DONE performs the same function as the 
CANCEL fucntion and also allows ne passive trade participant in the Workdown 
State to remove themselves from trading lists, thereby effectively removing their 
committed sizes before the system has had a chance to execute them. UNDO 
functions to "unroll" the trade and reduce the size shown to customers if 
executed during a predefined time period after the initial trade. Additionally, 
the UNDO function proportionally reduces the amount traded by all passive 
makers. The restriction of a predefined time period discourages one player from 
taking unfair advantage of this correction facility. Analogously, if more than 
one trader participated in the trade, then the UNDO function causes the trader to 
join the contra side for the size desired to be undone. The UNDO function can 
be invoked at any time by any participant, on the active side or the passive side; 
the system uses appropriate logic to maintain the fairness of the trading protocol. 

During the Workup State, a trader can use the DONE function to remove 
him/herself from being a participant from the active side or the passive side, or 
both sides simultaneously, regardless of the size traded or solicited. Thus, the 
DONE function logically removes the trader from the trade. The UNDO 
function can also roll back the trade provided that the first active trader has 
executed this function with a predefined time period following the trade. If the 
UNDO function is not invoked during this predefined time period, or the trader 
is not the first active trader, then the trader is entered in the queue to buy or sell 
on the contra side immediately. Preferably, the trader is placed at the top of the 
list so that the UNDO function can be effectively invoked immediately, provided 
there is a contra trader. Most preferably, the rights of the first active and 
passive traders will be maintained to assure fairness. 
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Although the invention has been described in detail for the purpose of 
illustration, it is to be understood that such detail is solely for that purpose and 
that variations can be made therein by those skilled in the art without departing 
from the spirit and scope of the invention except as it may be limited by the 
claims. 
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What is claimed is; 

1. In combination in a data processing system for implementing a 
structured trading environment for transacting the purchase and sale of select 
items having a predetermined set of characteristics wherein said data processing 
system is operated by a plurality of brokers representing one or more customers 
of said items and said brokers are bringing together said customers into a 
specific communication platform to permit exchanging positions regarding offers 
and bids relating to said items, comprising: 

a plurality of workstations comprising a display means for presenting to a 
broker or trader information about pending market conditions as they relate to 
said items being traded and the select positions taken by participating customers 
in regard to said items; 

a central server, linked to said workstations by a communication means 
and programmed to support a predetermined trading control logic wherein said 
trading control logic comprises a protocol of trade sequences directed to 
implement trading commands from said customers in a predefined way 
corresponding to the development of a plurality of trade specific states defining 
the ability of various traders to participate in said trading activity; and 

a communication means for distributing market information to said 
plurality of workstations in accordance with said trading control logic. 

2. The trading system of claim 1 wherein said protocol is defined by 
a stored program comprising a logic structure that defines conditions where a 
customer becomes a trader and conditions where other customers may 
participate in a trade. 

3. The trading system of claim 1 wherein said trading commands 
comprise bids, offers, hits and lifts. „ ■ 
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4. The trading system of claim 1 wherein said trading states is 
comprised of a Bid/Offer State and a Workup State. 

5. The trading system of claim 1 wherein said trading states further 
comprise a When State. 

6. The trading system of claim 1 wherein said trading states further 
comprises a Second Look State. 

7. The trading system of claim ] wherein said trading state further 
comprise a Workdown State. 

8. The trading system of claim 1 wherein said display provides a 
presentation of a bid side and an offer side of a market. 

9. The trading system of claim 8 wherein said display further 
provides information as to the size of uncleared bids and/or offers. 

10. The trading system of claim 8 wherein said display further 
provides a queue of customers organized in groups corresponding to their 
respective participation on the bid or offer side of the market. 

11. The trading system of claim 10 wherein said customer queue is 
ordered by time of entry. 

12. The trading system of claim 11 wherein said queue order is further 
based on quality of entry in terms of price. 



13. The trading system of claim 12 wherein said display provides 
information regarding the entry of a hit or lift by a trader. 
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14. A computer trading system for use by multiple traders wherein 
each trader operates a custom designed keypad for data entry and receives 
information about market conditions from a display comprising: 

a data processor with associated data storage for providing a trading 
protocol that establishes trading hierarchy among participants; 

a trade command input means including said custom designed keypad 
wherein said keypad includes a plurality of trade execute keys, individually 
assigned to a particular security available for trading, said keypad further 
comprises a plurality of customer entry keys assigning trade commands to a 
particular customer; 

a display means for presenting a trading information profile wherein said 
trading profile includes pending offers and bids at select price points and size. 

15. The trading system of claim 14 wherein said input means provides 
single keystroke entry for trade cancel command. 

16. The trading system of claim 14 wherein said data processor 
provides for a Bid/Offer State wherein customers' price and size are displayed 
on said display means. 

17. The trading system of claim 16 wherein said Bid/Offer State is 
terminated by a customer entry of a hit or lift command. 

18. The trading system of claim 16 wherein said Bid/Offer State is 
moved to a "When" State by a new customer entry of a hit or lift. 

19. The trading system of claim 14 wherein said display means 
presents information on trade transactions and customer access contingent on 
system trading state. 
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20. A method of financial instrument trading implemented on a 
distributed workstation computer system, wherein said system provides for a 
predetermined trading protocol delineating trader access comprising the steps of: 

a. providing a Bid/Offer System State wherein customers participate 
by entry bids, offers, price and volume information; 

b. distributing said information to said plural workstations in 
essentially real time; 

c. receiving hits and/or lifts from said customers responding to 
pending bids/offers as displayed on said workstations; 

d. entering a Trading State wherein transactions are completed at a 
single price; 

e. returning to the Bid/Offer State after a pre-established termination 
event in said Trading State; 

f. tracking and outputting consummated trades from said Trading 

State. 

21. The method of claim 20 wherein said Trading State is further 
delineated into a Workdown and a Workup State. 

22. The method of claim 21 wherein said Workup State is created by a 
single customer hitting or lifting all pending size. 

23. The method of claim 22 wherein said Workdown State is created 
by a customer hitting or lifting less than all of said pending size. 



24. The method of claim 20 wherein said trading protocol is encoded 
in programming logic controlling said computer system. 
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